Indeed.

However we express the location and name of a venue, we need to have it
as an object type so that it can be referred to as the actor, object or
target of an activity. In practice it might just be called "place" if
there's no use-case for specializing places where events typically
occur, but that remains to be seen.

Example use-cases for a venue or place object type are:
* Venue-specific notes and reviews on sites such as Last.fm, Eventful, etc.
* Checkins and other location-sensitive things on
BrightKite/FourSquare/etc. (We may find that we can represent this in
some other way, of course, such as an activity of posting a note with
location context.)
* On sites where venues are a social object -- of which there are many
including BrightKite/FourSquare/Last.fm/Eventful/Eventbright/Upcoming...
-- there's the usual social object interactions such as adding a new
one, editing an existing one, sharing one with a friend, etc, etc.

"Other formats" don't help us because we're in Atom, so whatever we
represent we need to figure out what it looks like in Atom. Sometimes
there's already a spec for representing something in Atom. Other times
there's some existing practice we can write into a spec. Sometimes there
are other formats that can be used as a basis for an Atom
representation, and in a few rare cases there is no existing precedent
and we need to make something up.

My goal now is to shrink the "core" or "base" schema as much as possible
and ultimately bake it so that others can start to implement without
fear that it'll change drastically as it has done a few times so far.
Then we can work on expanding out the more specialized sections.